


                             XMODEM and COMPUSERVE

                                 October, 1984



                    NOTE:  XMODEM,  like  the  rest  of  the
                    CompuServe   Information   Service,   is
                    provided  on  an  "as-is,  as-available"
                    basis.


                             Questions and Answers
                             ---------------------

          Question: Why doesn't XMODEM work with my PC-Talk program?
          Answer:   PC-Talk  works   just   fine   with   CompuServe's
                    implementation of the  XMODEM  protocol,  but  you
                    need to be running 8 bits / no parity in order for
                    PC-Talk to do XMODEM.
          See:      Section 4.2


          Question: I download a file using XMODEM, but all I get  are
                    a bunch of hexidecimal characters (something like:
                    :1800100AB759CDEF7) What I doing wrong?
          Answer:   You need to specify that  you  are  downloading  a
                    binary file, rather than a text file.  You can  do
                    this by appending a "/type:bin"  in  the  download
                    command (for example:
                         dow chess.bin/proto:XMODEM/type:bin )
                    or by selecting transfer type 2 (Binary) from  the
                    download menu.
          See:      Section 3.2


          Question: I download a file using XMODEM, but all I get is a
                    very short file full of garbage.
          Answer:   You may be trying to download an ASCII (text) file
                    as if it were a binary file.  Append "/type:ascii"
                    to the  filename  in  the  download  command  (for
                    example:
                         dow chess.txt/proto:XMODEM/type:ascii
                    or  select  transfer  type  1  (ASCII)  from   the
                    download menu.
          See:      Section 3.2


          Question: My   Crosstalk   program   doesn't    work    with
                    CompuServe's XMODEM!
          Answer:   Crosstalk XVI 3.4 has some compatibility  problems
                    with CompuServe, and cannot be used as is.   There






                                     - 1 -








     XMODEM on CompuServe                                      October 1984


                    is a patch  in  the  IBM  PC  Sig's  XA5  database
                    (called CISXTK.TXT) which  can  be  used  to  make
                    Crosstalk  work  well  with  CompuServe.    Future
                    versions  of  Crosstalk  should  work  well   with
                    CompuServe.
          See:      Section 4.1


          Question: My <fill in the blank>  terminal  program  doesn't
                    work with CompuServe's XMODEM, but it  works  just
                    fine with  everybody  else!  What  are  you  doing
                    wrong????
          Answer:   The XMODEM protocol was never  designed  with  the
                    idea of  communicating  over  a  packet  switching
                    network to  large  time  sharing  computers.   The
                    biggest problem  comes  from  the  fact  that  the
                    network introduces delays between the host and the
                    micro and that the host may not be able to respond
                    quickly to the micro's communications.

                    Most terminal programs do  work  with  CompuServe,
                    and many that do not can be patched to  work  with
                    CompuServe (e.g., Crosstalk)  by  simply  relaxing
                    the timing parameters in the program.
          See:      Section 3.1

          Question: Does  your  XMODEM   implementation   handle   CRC
                    checking as well as checksumming?
          Answer:   Yes.
          See:      Section 2

          Question: Where can  I  find  documentation  on  the  XMODEM
                    protocol?
          Answer:   The  closest  thing  to   an   official   document
                    specifying the XMODEM protocol is  a  small  notes
                    file Ward Christensen wrote describing  the  basic
                    protocol.  This file can be found in many  of  the
                    SIGs on CompuServe.
          See:      Reference [1].















                                     - 2 -








     XMODEM on CompuServe                                      October 1984




          0.        Abstract

          CompuServe has implemented a version of the XMODEM  protocol
          that allows most XMODEM users to successfully transfer files
          securely between their micros and CompuServe's hosts.   This
          implementation was not and cannot be 100%  faithful  to  the
          original XMODEM specification (see reference [1]),  and  the
          differences between micro to micro XMODEM and micro to  host
          XMODEM has caused some people problems.  The purpose of this
          short article is to describe, in detail, the  most  frequent
          problems people have with micro to host XMODEM, and to offer
          some suggestions on how to overcome these problems.


          1.        XMODEM's origins

          The XMODEM (aka MODEM7) protocol was originally  devised  by
          Ward Christensen as a  protocol  for  communicatons  between
          microcomputers.  As it was originally devised, the user runs
          a program called "MODEM", and  dials  up  another  computer.
          The user then instructs the remote computer to run a program
          called "XMODEM".  XMODEM  and  MODEM  then  use  the  XMODEM
          protocol to transfer files between the two computers.

          The XMODEM protocol has several assumptions implicit in  its
          design, and these assumptions are the source of the problems
          people have in using XMODEM protocol on CompuServe.  Some of
          these assumptions are:

               o File lengths are exact multiples of 128 bytes.
               o Word size is 8 bits on both computers.
               o Data is transmitted 8 bits, no parity, one stop bit.
               o Both   computers   are   dedicated   (single    user)
                 microcomputers.
               o Both computers are talking  to  each  other  directly
                 over a phone line.


 
         2.      The XMODEM protocol

          The XMODEM protocol is a half duplex protocol --  infomation
          travels in only one direction at once.  The  basic  protocol
          works something like this:

               1.  When the receiver is ready to start receiving data,
                   it  transmits  a  <nak>  (negative  acknowledgment)






                                     - 3 -








     XMODEM on CompuServe                                      October 1984


                   character to the sender, and  continues  to  do  so
                   every 10 seconds until:

               2.  The sender sends a block.  Each block contains  the
                   block number (modulo 256), 128 bytes of data, and a
                   checksum.  Once the block is sent, the sender waits
                   while:

               3.  The receiver verifies that he  received  the  block
                   correctly; if the received checksum  matches,  then
                   the receiver sends  an  <ack>  character,  and  the
                   sender sends the next 128 bytes of the  file  (step
                   2).  If the block was not received correctly --  or
                   if 10 seconds expires before a  complete  block  is
                   received, the receiver sends a <nak>  character  to
                   the sender.  When the sender receives a  <nak>,  it
                   re-transmits the last block.

               4.  Steps 2 & 3 are repeated until the end of the file.
                   At the end of the file, the sender sends  an  <eot>
                   character instead of a block of data.

               5.  When the receiver sees the <eot>, it sends an <ack>
                   to the  sender,  and  then  the  file  transmission
                   process is complete.


          There is a variant of the XMODEM  protocol  that  CompuServe
          also supports, called  the  CRC  option.   In  the  original
          XMODEM protocol, the checksum of each  block  was  only  one
          byte long.   This  small  of  a  checksum  (along  with  the
          algorithm used to generate it) allows errors to easily sneak
          into a supposedly error free protocol.

          The CRC option works roughly  like  this:   Instead  of  the
          receiver sending out <nak>s at the very beginning, it  sends
          out the letter "C".  If the sender has the  CRC  option,  it
          treats this just like a <nak>,  but  knows  to  compute  the
          two-byte CCITT CRC-16 and add it to the end  of  all  blocks
          instead of the one byte checksum.  If the  sender  does  not
          have the CRC option, then the "C" character has  no  meaning
          to it and is ignored.  The receiver may try about three "C"s
          before deciding that the sender will not  handle  CRCs,  and
          then  the  receiver   transmits   a   <nak>   to   start   a
          checksum-XMODEM file transfer.

          3.      XMODEM Problems on CompuServe







                                     - 4 -








     XMODEM on CompuServe                                      October 1984


          Because of the assumptions  made  in  the  XMODEM  protocol,
          various difficulties arise in using XMODEM over  CompuServe.
          Here are some major classes of problems:

          3.1     XMODEM Timing

          Since  XMODEM  was  originally  devised  for  micro-to-micro
          communications,  it  has  some  problems  fitting  into   an
          environment where one of  the  computers  happens  to  be  a
          mainframe and the two computers are  not  connected  over  a
          simple phone  line  but  via  a  packet  switching  network.
          CompuServe's network can often introduce long delays in what
          should be continuous communications,  as  can  a  very  busy
          host.

          When these delays arise, the  microcomputer  running  XMODEM
          may mistake them for a breakdown in  communications.   If  a
          long delay occurs in the middle of a packet -- in the middle
          of the data --  many  XMODEM  implementations  see  that  as
          meaning there has been data lost.  These  delays  result  in
          the following symptoms:

               o The receiver cannot  successfully  receive  even  the
                 first block of data.
               o The receiver consistently <nak>s blocks or  <nak>s  a
                 majority of blocks, although eventually receives  the
                 file.
               o The receiver just suddenly gives up in the middle  of
                 a seemingly successful file transfer.
               o The receiver has great difficultly in  receiving  the
                 file, and gives up  anywhere  from  5  to  20  blocks
                 through the  transfer.
               o The file transfer proceeds very smoothly with several
                 successfully transfered blocks when all of  a  sudden
                 every block transmitted is rejected (<nak>ed) by  the
                 host.


          Note that all of these problems are  indistinguishable  from
          other communications problems (e.g., noisy phone lines,  bad
          parity settings).  A key question  to  ask  people  who  are
          having XMODEM problems is "Have you ever successfully done a
          XMODEM transfer to CompuServe?"  If the answer is yes,  then
          the following problems may be at fault.

          3.1.1   Delays within blocks

          The XMODEM documentation [1] recomends that a  gap  of  more






                                     - 5 -








     XMODEM on CompuServe                                      October 1984


          than 1 second be treated as a breakdown  of  communications.
          On a microcomputer, this makes sense -- there is  no  reason
          for a dedicated micro computer to suddenly stop transmitting
          and then resume.   But on CompuServe's systems and  network,
          a  1  second  delay  is  not  only  possible,  but   happens
          frequently!

          If the microcomputer decides that this delay is a  breakdown
          of some sort, it will send a <nak> to CompuServe, requesting
          that the block be retransmitted.  Unfortunately, the rest of
          the first block is still "in  the  pipe"  --  and  when  the
          receiver gets this block the receiver may do  anything  from
          abort the transfer to  ignore  it.   Assuming  the  receiver
          handles the rest of the block gracefully (and  the  rest  of
          the block doesn't look like the start of another block), the
          host will see the <nak> the receiver sent and retransmit the
          block.   If  there's  a  delay  in  the   middle   of   that
          transmission, the receiver will <nak>  it  too,  and  so  on
          forever.

          Thus, when the receiver is too sensitive to  delays  in  the
          middle of transmissions, either the receiver gives  up  very
          quickly or the receiver <nak>s every block transmitted.

          3.1.2   Delays between blocks

          Fortunately, most implementations  of  the  XMODEM  protocol
          aren't that sensitive to delays in  the  middle  of  blocks.
          But other delays can cause problems too.  When  a  block  is
          received by the microcomputer, for example, the  micro  will
          almost immediately <ack> or <nak> the block and wait for the
          next block to be sent.  The XMODEM specification [1]  states
          that if the next block does not arrive  within  10  seconds,
          the receiver should send its <ack> or <nak> again.

          Ten seconds is not a  very  long  time,  however,  when  the
          network and/or mainframe is  heavily  loaded.   Often,  what
          will happen is that the <ack> or <nak> will  arrive  at  the
          host, the host will begin transmission of  the  next  block,
          but the block won't make it to the micro in time.  Then, the
          micro transmits a <nak>, even though the host has  correctly
          received the first <ack>/<nak>.

          What happens, then, is that a   <nak>  enters  the  network,
          even though the host has seen and  responded  to  the  first
          <ack> or <nak>.  After that, things can easily degrade.  The
          host may find  itself  one  block  ahead  of  the  receiver,
          causing the receiver to give up on the spot.  The  host  may






                                     - 6 -








     XMODEM on CompuServe                                      October 1984


          find itself stuck one <ack> or <nak>  behind  the  receiver,
          which could result in a successful, although very difficult,
          file transfer.  And the network  problems  could  be  severe
          enough -- or the micro sensitive enough --  that  the  micro
          goes through about 6 or so blocks (mostly <nak>s with a  few
          <ack>s) and gives up.

          3.1.3   Network Flow Control

          When the user is sending data to CompuServe, the  node  will
          send an XOFF (^S) character to the micro  if  the  micro  is
          transmitting faster than the node can send the data  to  the
          host.  This happens even during an XMODEM transfer (although
          very infrequently).  If the micro misinterprets the ^S as  a
          <nak>, it will immediately retransmit the block  --  causing
          the network to send even more ^Ses and the micro to see even
          more naks.  Usually what happens is that  the  micro  thinks
          that every block it transmits  is  being  <nak>ed,  and  the
          micro gives up almost immediately.  This problem can  strike
          anytime during an upload to the  host,  and  things  can  be
          proceeding very smoothly upto that point.

          3.1.4   Timing suggestions and hints

          To overcome and avoid these  problems,  an  XMODEM  protocol
          implementation should wait 20 seconds before sending a <nak>
          on a lost block, wait at least 10 seconds during  delays  in
          the middle of a block, and honor (or at least  ignore)  flow
          control from the node during uploading of files.

          Many programs which have timing problems with CompuServe can
          be patched to relax their timing  restrictions.   A  typical
          place to look is for calls to a "timed input" routine (where
          the routine will only  wait  so  long  for  a  character  to
          arrive).  Either patching that routine (make it  wait  twice
          as long, perhaps)  or  patching  the  code  that  calls  the
          routine (to use a longer time out value) would help to  make
          the XMODEM work on CompuServe.

          3.2     Host file Format Concerns

          3.2.1   The Host file format problems

          While almost all microcomputers  have  an  8  bit  word  (or
          multiple of 8 bits), CompuServe has a  36  bit  word.   Text
          files are stored with 7 bit bytes  (5  of  them  per  word).
          While this poses no problems for pure  text  files  (as  the
          ASCII character set is defined for only  7  bits  of  data),






                                     - 7 -








     XMODEM on CompuServe                                      October 1984


          "binary" files cannot be stored as is on  our  host  systems
          (an example of binary data would be an  executable  program,
          or a WordStar file).  Files in which 8 bits of data per byte
          must be preserved -- binary files -- are stored in a special
          file format (currently Intel hex format).

          Thus, when people upload or  download  to  CompuServe  using
          XMODEM, they are asked:

                  Transfer types available,

                   1 - ASCII  (7 - bit)
                   2 - Binary (8 - bit)

                  Please make a selection:

          People often pick the wrong answer, the results  are  either
          an unsuccessful or useless upload or download.

          3.2.2   The correct approach

          For uploading, the choice of  a  transfer  type  can  be  as
          simple as: "If it's a text file, use ASCII.   If  it's  not,
          use binary."

          For downloading, the correct transfer type is the  same  one
          that was used to upload the file,  i.e.,  if  the  file  was
          uploaded with an ASCII transfer it must be  downloaded  with
          an ASCII transfer; if the file was uploaded  with  a  binary
          transfer it must be downloaded with a binary transfer.

          At the moment, it is a problem for users to determine  which
          type the file was uploaded in.  Many SYSOPs have the  file's
          description specify the correct  approach  for  downloading.
          Other SYSOPs enforce the convention that files with a ".BIN"
          extension should be  downloaded  with  the  binary  transfer
          while other files should use the  ASCII  transfer.    It  is
          best to ask what policy is in use if there is some doubt.

          In the future, the SIG program will be improved so that  the
          choice of which  transfer  type  won't  be  asked  during  a
          download.

          3.2.3   What happens if...

          The user downloads a binary file with ASCII mode?

               The user gets the Intel hex format of  the  file.   The






                                     - 8 -








     XMODEM on CompuServe                                      October 1984


               downloaded file can be salvaged by use of a program  to
               convert Intel hex format back  to  binary.   Currently,
               the IBM Novice  forum  (PCS-129)  has  such  a  program
               available.

          The user downloads an ASCII file in binary mode?

               The user usually receives one or two blocks of  garbage
               data, at best.

          The user uploads a binary file in ASCII mode?

               The file transfer will not succeed, and any files  left
               over after the upload will be useless.

          The user uploads an ASCII file in binary mode?

               The file transfer will succeed, but the  uploaded  file
               will be encoded  into  Intel  hex  format.   Thus,  any
               people who download the file in ASCII mode or  use  the
               Read command will receive a hex representation  of  the
               file.  People who download the  file  in  Binary  mode,
               however, will be able to receive the file correctly.


          4.      XMODEM and ....

          4.1     CROSSTALK (XTALK), version 3.4

          Crosstalk has its timing  parameters  set  too  sensitively.
          Thus, it is virutually impossible to perform transfers using
          Crosstalk.  MicroStuff,  the  creators  of  Crosstalk,  have
          provided a patch to their software which allows it work with
          CompuServe.  This patch can be found in  the  IBM  PC  SIG's
          database (see reference [2]).



















                                     - 9 -








     XMODEM on CompuServe                                      October 1984


          4.2     PC-TALK III

          PC-Talk will work fine with CompuServe, so long as the  user
          is running PC-Talk in 8 bits / no  partiy  mode.   The  most
          recent version(s) of PC-Talk are set up to switch to 8  bits
          / no parity automatically on an XMODEM transfer,  but  these
          versions are still rare in the user community.


          By default, CompuServe communicates in 7 bits, even  parity.
          Thus, before PC-Talk can be thrown into 8  bits  no  partiy,
          the user must tell CompuServe to talk 8 bits no parity.

          The steps involved in making this change are as follows:


               1.  The user must log into CompuServe as usual (i.e., 7
                   bits even parity).

               2.  The user must then run the Default  program.   This
                   program can be reached either by typing "R  DEFALT"
                   from command mode in the personal  file  area  (the
 
                  "OK" prompt), or by typing "GO DEFALT" from any "!"
                   prompt.

               3.  In Default, the user should select option #5, "View
                   or Change current terminal parameters."   Then,  he
                   should  select  option  #8,  "Parity  is",   change
                   parity to ZERO, and then exit the default  program,
                   making all changes permanent.

               4.  At this point, PC-Talk can be switched into 8  bits
                   no parity.  On some modems (but  not  most  of  the
                   Hayes line of modems), doing this switch will cause
                   the modem to hang up.  Thus, it may be advisible to
                   log off CompuServe before switching to  8  bits  no
                   parity.

               5.  Once PC-Talk is  running  in  8  bit  mode,  it  is
                   possible  to  easily  upload  and  download   using
                   XMODEM.



          The next time the user dials into CompuServe (with  PC  Talk
          set to 8 bits no parity) and types control-c  to  catch  the
          system's attention, the "User ID:" prompt will  be  garbled.
          Once  the  system  recognizes  the  User  ID,  however,  the






                                     - 10 -








     XMODEM on CompuServe                                      October 1984


          password prompt will be  presented  in  clear  text.   Thus,
          users should just muddle through the garbled User ID  prompt
          and everything will work well after that.


          If the user's modem does not hang up when the parity setting
          is changed, it is also possible  to  change  to  8  bits  no
          parity just before performing an XMODEM transfer, and change
          back to 7 bits even parity when it  completes.   This  is  a
          rather  involved,  manual  process,  though,  and   is   not
          recomended.

          Note: Putting PC-Talk into 8 bits  no  parity  is  necessary
          even to upload or download ASCII files.








































                                     - 11 -








     XMODEM on CompuServe                                      October 1984


                                   References
                                   ----------


          [1]  "Modem Protocol Overview" by Ward  Christensen.   Found
               various places throughout  the  system,  including  the
               Programmer's   SIG's   XA2   database   in   the   file
               "PROTO1.DOC".  This document is the starting point  for
               anyone  desiring  to  implement  the  XMODEM  protocol,
               although the changes  and  suggestions  presented  here
               should be kept in mind.

          [2]  Crosstalk XVI 3.4 patch.  Found in the  IBM  SIG's  XA5
               database in the file CISXTK.TXT.   This  requires  some
               sophistication on the part of the user, as it  involves
               patching Crosstalk using the PC-DOS debug program.






































                                     - 12 -


